Batch 2 - Class 303 - Crypto Currency - Bitcoin

• MartinShColl 2.4 - Three points are selected at random on a sphere's surface. What is the probability that they fall within the same hemisphere?
• Answer: 1 (It is a certainty)

• Salability - across target goods, across time, across space
• Permanence - what happens it its not? Then people want to spend quickly rather than saving. The medium of exchange should be able to hold value
• Stock to flow ratio - For value to be permanent, someone should not be able to product a lot of it easily (otherwise value drops) 
• Liquidity (not scarcity!)
• Uniformity - to ascribe value to each piece uniformly. 
• Granularity - ability to break into subparts, so that smaller transactions can take place
• Easy to carry and transport
• Problem with centralized currency - the issuer has an incentive to print more and hence "rob" everyone else. This includes national governments as well as holders of reserve currency like US. So the "stock-to-flow" ratio can be compromised. In fact, that is why governments want to control money
• What has this got to do with Bitcoin? Let us map bitcoin against the characteristics of sound money we listed earlier
• Total supply of bitcoin is limited to about 21 million ever. Of those 20 million will be mined by 2025, so very good stock-to-flow ratio (currently we are at 1.7% so like Gold. By 2025 it will be half of that)
• Each bitcoin is divisible into 100 Million units called Satoshi - so it can be used in a granular fashion
• Adoption and usage is growing from 32K transactions in 2009 to more than 150M in 2021. 
• It is easy to transport - electronically
• It is easy to verify - no one can claim to own more than they do
• It still suffers from volatility and this remains the key drawback
• It has high transaction costs so it is not amenable to lot of low value transactions

• What is encryption - take simple example of shift cipher. Or number locks - if two people know the code, then they can safely transmit a message. In cryptography, we will call this code the symmetric encryption key. This requires a secret key to be established between every pair of people.
• How do we scale this up? What if we don't want every pair of people to have their own set of keys that must be kept private? How do we ensure that we can still send secret messages
• What if we had a pair of keys, one of which is private to a person (not to a pair) and the other is public to everyone. The key property is that anything encrypted with a public key can be decrypted with the corresponding private key and vice versa. This of these as poison and their respective antidotes - or magic potions. Or "inverse colors" - two colors which when combined undo each other (i.e. product no color) - mixing colors is easy, but separating colors is hard. (Explain notion of "hard" in mathematics)
• How would we send a private message to someone?
• What will happen if I encrypt something with my private key and send it out - any one can decode it. But this can be used as my unique signature!
• Hash functions - are functions that create a short digest of a message, not matter what the message is. But it does so in a one-way fashion. So you can find the digest easily if the message is given. But you cant find the message if the hash function is given. Note that this "one way" property is central to cryptography

• Lets start with a simple system to record transactions between a few friends. Each of them do shared expenses, and record that. Note that like a rupee, its a "promise to pay", which can be settled every once in a while. Lets say you create a website where anyone can update these transactions.

• Ask kids to do so on the whiteboard. There are likely to be random transactions that the other party does not confirm. That illustrates the problem with this system
• This system lacks integrity of transactions. Both people, especially the payer, should be able to confirm that this transaction is valid. 
• This requires digital signatures - equivalent of normal signatures. For now, we can assume that this is like a mail from the payer, saying that she agrees to the transaction. We are assuming that emails can't be forged. In reality, there are foolproof ways of obtaining digital signatures.
• Introduce basics of public and private key if required. Signature(Message, PrivateKey) gives the digital signature; and Verify(Message, DigSig, PublicKey) verifies it. DigSig is 256 bits, so one can't randomly guess the digital signature for a particular message. We also include a unique id on each message, so that the same message signature can't be replicated.
• So you now have a revised system and the ledger looks like 

• Whats the problem now? What if one of the people refuses to settle? How can we solve for that?
• How do we solve for that in real life? How do we prevent people from spending too much money that they don't have? We only allow them to spend what they have or what they are due to receive.
• So lets say we started everyone out with $100 of cryptocurrency (which they pay into the pool). And now they can only owe $100 plus whatever others owe them.
• What will the first lines of ledger look like? "Alice gets $100 from the pool" and so on.
• This requires the system to know and verify all transactions in order to validate a future transaction.
• We also potentially have a problem that someone may transmit the same message (with same signature) twice - how can we solve that? We can associate a unique id with each transaction - like a random number, which is included in the signature
• This now allows someone to lead their whole life on the ledger. Remember, a rupee is only a promise to pay. A ledger is a promise to pay. There is not other "real" meaning to money of any sort! We can call them Ledger Dollars. We can exchange LDs for Rupees on an exchange just like we can exchange USD for Rupees. (Remember, when US asked people to deposit their gold and issued US Dollars against that - they basically kickstarted this ledger by issuing IoUs)
• What is the problem now? Who controls the website? How do you trust the website? In case of Rupee, we trust the central bank by fiat. How do we solve this problem?
• We let everyone keep a copy of the ledger for themselves
• What is the problem with this - how do we know which one is the true copy of the ledger? How do we ensure that all ledgers are getting updated in real time (so that they can compute the entire history when validating the last transaction)
• So when you hear a transaction, how do you accept/reject it, and be sure that everyone else will make the same decision? And for this to happen in the same sequence?
• Recap - the protocol so far is "Broadcast transactions", "Only accept signed transactions", "No overspending" - so for example, one can still be missing some transactions, or deliberately delete them
• This involves "proof of work". First, brief on Hash functions - Hash(Message)=256-bit-string. Easy to compute in forward direction. Almost impossible (computationally) to reverse engineer.
• So now if someone gives a ledger and a number, and claims that first 30 digits of the hash for that combination are 0s, then the person would be gone through 2^30, i.e. a billion hash computations to find that number (Note: it could be less or more, but its a billion expected attempts). Verifying that number, however, is easy (1 computation). This is called proof of work - that you can verify that they went through large amount of work efficiently.
• This whole computation is done on blocks of ledgers, rather than on the whole ledger. And to make sure the blocks fit in sequence, we will include the hash of previous block at top of the next one before computing the next one's hash. (So if you change one entry in one block, all the subsequent block hashes become invalid). That is why we call it Block Chain.
• So now anyone can be a block creator - they listen to transactions, assemble them into blocks, do the work to compute the special number, and then transmit the block to everyone else to add to their chain. The block creators are rewarded by small amounts of money, which they can add at top of that block. Creating blocks is called Mining, and it introduces new currency into the system.
• So multiple miners are trying to compute the special number for the same block, and whoever gets there first, gets paid. 
• What is the problem now? If you get conflicting block chains, which one do you trust? The protocol is that you trust the longest one - one where there is maximum proof of work! So instead of trusting a central authority, you trust computational work! Is this enough?
• Why wouldn't the fraudster try to do this on an inaccurate ledger and transmit to everyone? Imagine that millions of people are trying to take copies of transactions they have "heard" and compute the number for their copies of the ledger. What are the chances that the fraudster gets to that computation first? This investment of significant "work" for low probability of rewards, especially for erroneous transactions, is what disincentivizes fraud. 
• At the same time, the recipient will hear other miners as well, and when those come in, this fraudulent block will get discarded (given that other miners collectively are putting in much more work than the fraud). Note that in case there are multiple valid blocks, the longest chain is picked, so that transactions are not eliminated by fraudsters.
• If someone truly has a disproportionate share of computing power for mining globally, then the incentive for that person is to use it legitimately and earn bitcoins by mining and transaction fees
• Since we are adding new currency all the time, what preserves the value of your bitcoin holding? 
• The reward for mining drops geometrically, and we know that the sum of an infinite geometric series is finite. So we know what the total reward will ever be!
• Miners can also earn a transaction fee per transaction, so that they can continue to get paid.
• All this work does add to the overhead in the currency system - something that other systems are trying to optimize on. Example, through proof of stake

• (Dudeney - 76) A man bought an odd lot of wine in barrels and one barrel containing beer. These are shown in the illustration, marked with the number of gallons that each barrel contained. He sold a quantity of the wine to one man and twice the quantity to another, but kept the beer to himself. Which barrel contained the beer?

• Answer: 20 gallons. This can be solve by trial and error. Or by noticing that the quantity of wine sold is a multiple of three, where as the digital root of sum of all barrels is 2. Hence the beer barrel must have a digital root of 2 + 0,3,6 i.e. 2, 5, or 8. That is only true of 20 gallon barrel.